Attaquer les processeurs par les registres de consommation d’énergie
jeudi 21 janvier 2021, par Gregory Fabre
Ceci est le résumé d’une conférence donnée le 28 décembre 2020 au RC3, le congrès annuel du Chaos Computer Club, qui cette année avait lieu en ligne uniquement.
Les auteurs de cette conférence sont : Moritz Lipp, Michael Schwarz, Daniel Gruss et Andreas Kogler.
J’ai réalisé un résumé en français de cette conférence pour l’OSSIR que j’ai présenté par visio conférence à une cinquantaine de membres le 12 janvier 2021. Il existe une vidéo enregistrée de cette présentation, cet article en est le résumé écrit.
La genèse de l’idée
Les chercheurs en sécurité font état d’une conversation entre eux de 2017, où l’idée germe d’aller lire le niveau de consommation d’énergie publié par les microprocesseurs modernes, et d’en déduire des informations sur ce qu’ils sont en train de faire, cette consommation augmentant avec la charge du processeur.
Si on pouvait ainsi attaquer le processeur en utilisant un accès physique, il serait encore plus intéressant de pouvoir le faire uniquement par une attaque logicielle.
De même, si on pouvait le faire grâce à un accès au niveau hyperviseur, l’idéal serait de pouvoir le réaliser depuis l’espace utilisateur, sans droit particulier.
Les registres RAPL
Les machines modernes ont besoin de gérer leur consommation électrique, par exemple pour éteindre leur disque dur ou leur écran. La consommation en temps réel est publiée, sur les processeurs Intel, grâce aux indicateurs RAPL (Running Average Power Limit), dans des registres dédiés.
Sur Linux, ils sont accessibles par le framework powercap dans /sys/devices/virtual/powercap
Sur MacOS et Windows, il convient d’installer un pilote spécifique.
Premières mesures
On fait répéter la même instruction au processeur un grand nombre de fois et on réussit à distinguer une différence de la courbe de consommation en fonction de l’instruction exécutée. On voit bien sur ce graphique que les courbes sont bien séparées.
On réussit également à différencier des courbes selon que les bits de l’opérande du calcul sont à 0 ou bien à 1, ou bien en fonction de la valeur déplacée par un MOV…
On peut aussi distinguer clairement si une valeur chargée en mémoire l’a été depuis la mémoire tampon (cache).
Le problème est que ces mesures ont pris 23 jours… bien que le principe de l’attaque est bien confirmé, on est encore loin d’obtenir des résultats opérationnels.
Avançons vers une attaque
Tentons une attaque par canal caché (Covert Channel). L’idée est d’ouvrir un canal de communication entre deux processus qui ne sont pas censés communiquer entre eux. L’un émet et l’autre tente de lire.
Lors de l’envoi d’un 1, on fait des opérations consommatrices, mais lors de l’envoi d’un 0 : on ne fait rien. On mesure l’énergie et on en déduit la valeur transmise.
Et ça marche ! On voit bien sur ce graphique que lors de l’envoi de la séquence 1101100011 on obtient un signal très clair.
Le résultat est le même par un canal caché entre deux machines virtuelles : le superviseur Xen donne accès aux registres RAPL et le signal est très clair.
Attaque du KASLR
Essayons d’attaquer le Kernel Address Space Layout Randomization. C’est un mécanisme de sécurité dans Linux qui reloge aléatoirement le noyau dans la mémoire. Le noyau ne peut être que dans un nombre limité d’endroits.
Si on ne le trouve pas on consomme plus d’énergie car le processeur doit se rendre compte qu’il n’y a rien à cet endroit. Si le noyau est là c’est dans le cache et cela utilise moins d’énergie.
Grâce à cette technique on trouve l’adresse du noyau ! C’est très prometteur !
Un peu de crypto
On pourrait également attaquer de la crypto, par exemple le chiffrement RSA, qui est un algorithme asymétrique (à clef publique et privée) très utilisé. Si on trouve la clef privée de l’utilisateur, alors on a cassé la sécurité de l’algorithme puisqu’on peut tout déchiffrer.
La formule utilisée par RSA est la suivante :
M=Cd(modn)�=��(mod�)
Où : -M est le message -C est le message chiffré -d est la clef privée -n est le produit des deux clefs
Si le bit est à 1 dans la clef privée il faut faire un « carré et multiplier ». S’il est à 0 on ne fait qu’un carré, or ces deux opérations ont une signature énergétique différente.
Pour observer les opérations on va utiliser SGX, qui est un jeu d’instructions étendu d’Intel. Il fournit des contrôles d’intégrité et de confidentialité dans des environnements non sûrs.
Afin de le contrôler, les chercheurs utilisent SGX-step, pour configurer les interruptions APIC.
L’idée est d’interrompre l’exécution de l’enclave pour lui faire faire du pas à pas comme avec un debugger, mais pour enclaves.
Combiné avec RAPL ils vont pouvoir mesurer la consommation d’une seule instruction.
Ainsi ils réalisent une enclave qui imite le « carré et multiplier » de RSA, ils l’exécutent pas à pas et mesurent l’énergie consommée.
Et ça marche ! Ils identifient des motifs répétitifs en fonction de l’instruction, ils trouvent un motif qui correspond aux 6 instructions exécutées pendant un « carré et multiplier ».
De la vraie crypto
Le résultat précédent n’étant qu’une preuve de concept, les chercheurs passent à une implémentation connue de RSA, incluse dans TLS 2.13.0.
C’est un peu plus compliqué que le « carré et multiplier » mais le principe est le même, ils identifient deux instructions qui consomment différemment dans le langage machine résultant.
De la même manière, ils multiplient l’exécution de ces instructions puis mesurent… et ça marche, ils obtiennent un signal très clair. De plus ils vont très vite, car le temps de recherche est linéaire par rapport à la taille de la clef, ce qui est un résultat très important en crypto. En quelques heures ils trouvent la clef privée !
Divulgation responsable
Ce processus a pris du temps, de 2017 à 2019. Les chercheurs ont évidemment appliqué la règle du « Responsable disclosure » et n’ont donc temporairement révélé la faille qu’aux vendeurs de processeurs, qui ont demandé un embargo de presqu’une année. Celui-ci se terminait en novembre 2020 ce qui a permis cette conférence.
Et sans droits d’admin ?
Rappelons que l’idée était de pouvoir attaquer pas uniquement avec SGX-step, mais depuis l’espace utilisateur, sans droits privilégiés.
Ainsi il était difficile de mesurer des petites parties de code sans l’aide de SGX-step. Ils ont donc reconstruit un modèle de consommation d’énergie, et découvert : -Un poids de « martelage » : plus de bits sont écrits, plus d’énergie est consommée -Une distance de « frappe » : Plus de bits changent, plus d’énergie est consommée
Ils ont alors changé de cible, et visé AES-NI, qui est une extension du jeu d’instructions de x86 pour Intel. L’idée est de pouvoir déclencher le chiffrement ou le déchiffrement de beaucoup de blocs, sur une longue durée par exemple : -Le chiffrement de disques -TLS -Le changement d’état de l’enclave
Le problème est que la clef est souvent scindée en plusieurs parties, il faut donc la reconstruire. Ils essaient une valeur et si la consommation est identique la valeur est la bonne. Puis ils répètent le processus pour chaque partie de la clef.
Le signal se stabilise avec le temps et ils réussissent à trouver la clef !
Tous les fondeurs sont affectés
AMD est affecté aussi, mais ils n’ont pas répondu. D’autres fabricants ont des interfaces similaires, qui devraient également être vulnérables : le problème semble bien affecter toute l’industrie.
La presse spécialisée, allemande et internationale, en a déjà un peu parlé.
Contremesures
La première contremesure consiste à supprimer l’accès sans privilège aux registres RAPL. Pour cela il suffit d’un patch d’une ligne pour le noyau Linux.
Mais le modèle de menace de SGX accepte un système d’exploitation compromis et donc un patch ne sert à rien, il faut des mises à jour de microcode. Cela permet de ne plus faire la différence entre données et instructions.
Conclusion
Quelle amusante conférence ! Certes un peu velue techniquement, mais très enrichissante sur ces nouvelles failles incroyables.